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For  many  years,  there  has  been  much  work  attempting  to  identify  a  set  of  best  practices  that  software-intensive  projects  could 
apply  to  aid  in  the  acquisition,  production,  or  upgrade  of  software.  Spurred  on  by  the  1987  and  2001  Defense  Science  Board 
findings,  rfforts  conducted  by  the  Software  Engineering  Institute  and  the  Software  Program  Managers  Network  have  identi¬ 
fied  and  documented  specific  practices  that  have  had  apparent  success  in  loweringproject  risk,  improving  cost  and  schedule  per¬ 
formance,  and  enhancing  user  satisfaction.  Since  Section  804  of  the  National  Defense  Authorisation  Act  for  Fiscal  Year 
2003  was  enacted  on  Dec.  2,  2002  and  became  law,  there  has  been  much  activity  in  this  area,  particularly  in  the  Department 
of  Defense  and  its  various  services.  This  article  explores  some  of  these  efforts,  looks  at  the  practices  that  have  resulted,  and 
attempts  to  examine  certain  key  relationships  that  must  be  considered  when  applying  them  to  projects. 


Best  practices  are  often  looked  on  as 
the  Holy  Grail  of  process  improve¬ 
ment,  the  silver  bullet  that  will  cure  all  ills. 
A  manager  might  reasonably  ask,  “After 
all,  couldn’t  I  expect  the  same  degree  of 
success  if  I  use  the  same  processes  in  the 
management,  engineering,  assurance,  and 
tracking  of  the  project?”  The  answer  is  an 
unqualified  maybe. 

Indeed,  far  from  being  a  silver  bullet, 
there  is  some  evidence  that  the  term  best 
practices  lacks  significant  meaning.  In  2001, 
Dr.  Richard  Turner  conducted  a  study  for 
the  Department  of  Defense  (DoD)  [1]  to 
identify  credible  best  practices  that  could 
improve  performance,  predictability,  qual¬ 
ity,  and  operational  effectiveness  while 
lowering  risk,  shortening  schedules,  and 
reducing  development  costs.  As  a  result  of 
this  study,  Turner  concluded  that  because 
the  term  best  practices  is  consistently  mis¬ 
used,  it  is  misleading  at  best  and  useless  at 
worst.  It  has  become  a  catchall  phrase  that 
bundles  diverse  ideas  about  practices  and 
frameworks,  and  is  used  by  some  to  legit¬ 
imize  unproven  practices,  tools,  or 
processes. 

Unproven  practices,  while  not  desig¬ 
nated  as  best,  are  often  essential  compo¬ 
nents  of  successful  projects.  They  simply 
do  not  have  a  pedigree  outside  of  the 
project  to  which  they  are  being  applied. 

Practice  Relationships 

Software  managers  must  not  assume  that 
just  because  a  certain  practice  has  been 
labeled  best  that  it  will  indeed  improve  the 
performance,  predictability,  quality,  and 
operational  effectiveness  of  the  software 
they  are  responsible  for  producing.  Nor 
does  it  mean  they  should  view  these  prac¬ 
tices  with  outright  suspicion,  but  only  that 
they  must  understand  the  advantages  and 
disadvantages  of  the  practices  for  their 
particular  projects  and  how  they  can  be 


usefully  adapted  to  the  various  needs  of 
their  organization. 

To  understand  why  so-called  best 
practices  are  not  a  silver  bullet,  it  is  impor¬ 
tant  to  understand  the  difference  between 
a  process  and  a  practice.  A  process  is  a  set 
of  interrelated  resources  and  activities  that 
transform  inputs  into  outputs.  When  used 
in  a  consistently  formal  manner,  these 
resources  and  activities  tend  to  increase 
quality,  shorten  schedules,  and  lower  cost 
and  risk.  Processes  are  used  to  conduct 
business,  and  they  support  a  unique  orga¬ 
nizational  culture.  Practices  are  disciplines, 
methods,  tools,  or  techniques  that  are  used 
to  accomplish  a  specific  function  or  set  of 
functions  in  a  project  environment.  A 
process  can  include  multiple  practices. 

A  process  can  be  considered  a  plan  in 
that  it  describes  what  must  be  done  to 
obtain  an  output  and  provides  the  frame¬ 
work  needed  to  accomplish  the  necessary 
tasks.  Practices  define  the  manner  in 
which  the  tasks  must  be  conducted.  Both 
are  critical  to  a  project’s  success  because 
what  is  to  be  done  must  be  planned,  and 
how  the  plan  will  be  accomplished  must 
be  defined.  Moreover,  practices  must  be 
adapted  to  the  organization  that  uses 
them,  and  the  relationships  between  the 
practices  must  be  understood  and  man¬ 
aged  if  the  expected  benefits  are  to  be 
realized.  It  is  incumbent  upon  the  manag¬ 
er  to  choose  practices  that  are  appropriate 
to  the  level  of  the  organization  that  will 
implement  them  and  adapt  them  as  neces¬ 
sary.  For  example,  a  practice  intended  to 
meet  the  configuration  management 
needs  of  the  acquisition  layer  of  an  organ¬ 
ization  would  not  necessarily  meet  the 
needs  of  the  development  layer,  but  with 
a  proper  understanding  of  its  uses,  a  man¬ 
ager  could  adapt  the  practice  to  meet  the 
needs  of  both. 

A  typical  program  has  several  layers, 


each  of  which  has  different  requirements 
and  constraints  regarding  the  processes 
and  practices  used  and  their  implementa¬ 
tion.  The  top  layer,  the  user  organization, 
requires  deployment  of  a  product  or  serv¬ 
ice  that  is  responsive  to  the  operational 
and  support  requirements  of  the  user 
community.  The  needs  of  the  user  com¬ 
munity  form  the  baseline  from  which 
required  practices  are  defined  and  imple¬ 
mented.  The  user  organization  requires 
practices  that  (1)  capture,  characterize,  and 
control  the  user’s  operational  require¬ 
ments  and  constraints;  (2)  define  interop¬ 
erability  and  system  interface  require¬ 
ments;  (3)  identify  how  these  require¬ 
ments  are  qualified  and  inserted  into  the 
operational  environment;  and  (4)  define 
how  these  elements  are  documented, 
maintained,  and  updated. 

The  next  layer  of  the  program,  the 
acquisition  organization,  is  chartered  to 
acquire  the  right  product  at  the  lowest  cost 
and  in  the  shortest  time  to  satisfy  a  speci¬ 
fied  user  requirement.  To  do  so,  the  acqui¬ 
sition  organization  works  with  the  user  to 
define  what  is  required.  It  then  converts 
the  user  needs  into  functional,  engineer¬ 
ing,  product  assurance  and  support 
requirements  and  constraints,  and  plans 
and  implements  processes  —  supported  by 
practices  -  to  acquire  a  system,  software 
product,  or  services  that  will  satisfy  the 
user  needs.  The  acquisition  organization 
next  prepares  and  issues  documentation 
that  establishes  agreements  between  the 
acquirer  and  supplier(s),  selects  a  suppli¬ 
er^),  and  manages  the  acquisition  process 
until  the  product  or  service  is  accepted. 

The  acquisition  organization  requires 
practices  that  facilitate  the  acquisition  of 
the  product  or  service  at  the  lowest  risk.  It 
needs  practices  to  collect  and  evaluate 
quantitative  indicators  of  both  project 
performance  and  product  quality;  to 
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assure  the  product’s  quality  based  on  the 
quantitative  indicators;  to  monitor  devel* 
oper  performance;  and  to  facilitate  deliv¬ 
ery,  acceptance,  and  deployment  of  the 
product  or  service. 

The  next  layer  of  the  program,  the 
development  organization,  is  chartered  to 
build  a  product  in  a  manner  drat  is  consis¬ 
tent  with  established  agreements  and 
specifications  and  that  maximizes  profit 
and  meets  all  commitments  and  agree¬ 
ments.  The  development  organization 
needs  practices  drat  (1)  specify  architec¬ 
tures;  (2)  define,  expand,  and  control  spe¬ 
cific  engineering  requirements  drat  are 
traceable  to  those  provided  by  tire  acquir¬ 
er;  (3)  control  and  manage  the  develop¬ 
ment  process;  (4)  monitor  the  quality  of 
die  products  being  developed  or  received 
from  suppliers;  (5)  collect  quantitative 
information  from  implemented  practices 
to  ascertain  process  effectiveness;  (6) 
monitor  cost  and  schedule  performance; 
and  (7)  monitor  development  risk  against 
progress  toward  established  requirements. 

Finally,  support  organizations  —  such 
as  independent  test,  logistics,  installation, 
product  maintenance,  etc.  —  require  prac¬ 
tices  drat  enable  processes,  and  provide 
management  visibility  into  and  control 
over  tire  quality  of  the  services  provided 
and  die  risks  that  must  be  addressed. 

Given  these  various  needs,  it  is  easy  to 
see  that  a  single  set  of  best  practices 
would  be  impossible  to  implement,  and 
drat  any  set  of  best  practices  must  be 
adapted  to  the  organizational  layer  that 
implements  them.  For  example,  best  prac¬ 
tices  related  to  configuration  management 
necessarily  must  be  adapted  to  meet  the 
needs  of  tire  user  level,  the  supplier  level, 
and  the  development  level.  Nevertheless, 
configuration  management  can  be  consid¬ 
ered  a  necessary  best  practice  that  all 
organizations  should  address  if  they 
expect  to  succeed. 

Once  adapted  to  die  needs  of  the  var¬ 
ious  organizations,  the  practices  must  be 
integrated  if  die  project  is  to  progress 
effectively  both  within  an  organization 
and  between  organizations.  For  example, 
the  requirements  management  process 
area  may  require  effective  implementation 
of  the  requirements  definition,  configura¬ 
tion  management,  defect  identification 
and  removal,  and  user  involvement  prac¬ 
tice  areas  to  accomplish  the  process. 

In  addition,  the  many  practices  a  par¬ 
ticular  organization  uses  must  interact 
with  other  practices,  which  are  often  unre¬ 
lated,  to  provide  seamless  and  effective 
support  to  the  overall  process.  For  exam¬ 
ple,  if  a  particular  practice  identifies 
defects  early  in  the  development  process, 


configuration  management  should  ac¬ 
count  for  this,  and  the  software  manager 
must  adapt  practices  to  remove  defects 
accordingly  to  ensure  potential  efficiencies 
are  realized. 

Sample  Practices 

Table  1  on  page  16  lists  several  project 
approaches  or  best  practices  that  have 
originated  from  initiatives  conducted  by 
various  organizations.  This  list  is  a  small 
sample  of  the  hundreds  identified  in  the 
literature  as  being  best  [2],  These  practices 
can  be  categorized  by  their  typical  applica¬ 
tion  or  use: 

•  Policy  Requirement.  A  policy  re¬ 
quirement  defines  a  basic  requirement 
drat  all  program  organizations  must 
meet.  This  category  focuses  on  a 
desired  outcome  and  typically  does  not 
define  specific  processes  or  practices. 

•  Organizational  Concept.  These  are 
general  principles  that  are  used  to 
organize  the  project,  allocate  resources 
and  responsibility,  enable  communica¬ 
tions,  and  effect  work  assignment. 

•  General  Strategy.  This  is  a  strategy 
drat  applies  to  all  organizational  com¬ 
ponents  of  a  project  but  must  be 
adapted  to  the  needs  of  a  particular 
organization  to  be  effective.  A  general 
strategy,  for  example,  might  be  that  all 
projects  apply  continuous  risk  man¬ 
agement  to  prevent  negative  conse¬ 
quences  from  unanticipated  issues. 
Although  related  to  die  risk  manage¬ 
ment  practices  of  other  organizations, 
specific  implementation  of  the  general 
strategy  within  an  organization  will 
depend  on  tire  organization’s  particular 
charter,  culture,  commitments,  and 
constraints. 

•  Business  Strategy.  This  is  a  strategy 
drat  defines  how  to  accomplish  specif¬ 
ic  business  tasks. 

•  Acquisition  Framework.  This  is  a 
structure  the  acquisition  organization 
uses  to  acquire,  manage,  and  control 
tire  products  or  services  and  ensure 
they  are  responsive  to  user  needs.  It 
usually  consists  of  activities,  specifica¬ 
tions,  reviews,  and  reporting  require¬ 
ments. 

•  Acquisition  Strategy.  An  overall 
statement  of  how  an  organization  will 
acquire  products  and  services  consis¬ 
tent  with  user  needs  and  requirements 
is  an  acquisition  strategy.  Expressed  in 
general  terms,  it  typically  describes 
requirements  that  will  constrain  die 
selection  and  adaptation  of  processes 
and  practices  and  defines  the  goals  that 
must  be  met  to  satisfy  validated  needs 
as  well  as  to  maximize  affordability. 


•  General  Practice.  This  is  a  practice 
that  supports  every  organizational  level. 
Specific  application  of  die  practice  will 
differ  according  to  the  needs  of  die 
user,  acquirer,  supplier,  and  support  lay¬ 
ers  of  die  program  organization. 

•  Development  Practice.  This  is  a 
practice  that  predominately  supports 
the  supplier’s  requirements. 

•  Acquisition  Practice.  This  is  a  prac¬ 
tice  diat  ensures  an  acquisition  is  con¬ 
ducted  effectively  by  die  acquisition 
organization  as  it  monitors  the  project 
and  controls  die  suppliers.  The  prac¬ 
tices  are  structured  to  evaluate  and 
receive  products  and  services  rather 
than  develop  and  deliver  them. 

•  Maturity  Model.  This  is  used  to  eval¬ 
uate  the  process  maturity  of  an  organ¬ 
ization  to  determine  the  potential  risk 
of  a  process  and  die  potential  to  use  it 
successfully  in  other  circumstances. 
Table  1  identifies  project  approaches, 

i.e.,  best  practices  that  have  been  extracted 
from  several  sources,  including  the 
Software  Program  Managers  Network  16 
Point  Plan,  die  DoD  Best  Practices  Study 
conducted  by  Dr.  Richard  Turner,  the 
European  Software  Institute  1977 
Software  Best  Practice  Questionnaire 
Analysis  of  Results,  and  various  other 
studies.  Some  of  the  approaches  are  relat¬ 
ed  to  policy,  others  are  related  to  process, 
and  still  odiers  are  related  to  strategy. 
However,  they  all  are  important  consider¬ 
ations  with  significant  benefits  diat  an 
organization  could  use  to  establish  an 
effective  project  environment  and  con¬ 
duct  the  activities  identified  in  their  proj¬ 
ect  plan. 

As  Norm  Brown  posits  in  IEEE 
Software  [3],  the  definition  of  a  small  num¬ 
ber  of  relevant  best  practices  can  have  a 
significant  effect  on  the  success  of  a  proj¬ 
ect,  but  only  if  the  practices  are  tailored  to 
the  needs  and  culture  of  die  organization 
that  will  use  them.  In  Table  1,  we  have 
identified  the  practice;  the  source,  includ¬ 
ing  die  primary  reference  that  was  used  to 
identify  it;  and  the  general  classification  of 
the  practice.  Turner’s  dissertation  [4], 
“Implementation  of  Best  Practices  in  U.S. 
Department  of  Defense  Software- 
Intensive  Systems  Acquisitions,”  is  identi¬ 
fied  as  the  source  for  many  of  die  prac¬ 
tices  included  in  the  table.  For  readers’ 
convenience,  we  have  included  the  source 
reference  for  die  specific  practices  identi¬ 
fied  in  the  Turner  dissertation. 

Basic  Considerations  for 
Implementing  Practices 

The  Turner  study  discusses  what  must  be 
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Best  Practices 


Practice  Identification 

Practice  Source 

Practice  Category 

Establish  Clear  Goals  and  Decision  Points 

(DSBTF,  5000.2R)  [5,6] 

Policy  Requirement 

Treat  People  as  the  Most  Important  Resource 

SPMN  16  Point  Plan  [7] 

Policy  Requirement 

Common  Management  and  Manufacturing  Systems 

(5000.2R)  [6] 

Policy  Requirement 

Integrated  Product  and  Process  Development 

(5000.2R,  Reifer)  [6,4] 

Organizational  Concept 

Appointing  Project  Managers  for  Each  Project 

ESI  [8] 

Organizational  Concept 

Software  Quality  Assurance  Function  with  Independent  Reporting  Line 

ESI  [8] 

Organizational  Concept 

Training  New  Project  Managers 

ESI  [8] 

Organizational  Concept 

Have  a  Formal  Review  or  Handover  of  Deliverables  From  One  Project  Group  to  Another 

ESI  [8] 

Organizational  Concept 

Maintaining  Awareness  of  New  Development  Technologies 

ESI  [8] 

General  Strategy 

Ensuring  User  Input  at  All  Stages  of  the  Project 

ESI  [8] 

General  Strategy 

Assess  Viability,  Risks,  and  Benefits  Before  Committing  to  a  Project 

ESI  [8] 

General  Strategy 

Conduct  Periodic  Reviews  of  the  Status  of  Projects 

ESI  [8] 

General  Strategy 

Demonstration-Based  Reviews  (Including  Executable  Architectures) 

(Royce,  DSBTF,  ISO)  [4,5,9] 

General  Strategy 

Conduct  Inspection  and  Walkthroughs  at  Each  Stage 

ESI  [8] 

General  Strategy 

Require  Structured  Development  Methods  (Iterative  Processes) 

(Royce,  DSBTF)  [4,5] 

General  Strategy 

Plan  for  Technology  Insertion 

(5000.2R,  DSMC)  [6,10] 

General  Strategy 

Commercial  and  Specifications  and  Standards/Open  Systems 

(5000. 2R,  Anderson,  Jones)  [6,4] 

General  Strategy 

Statistical  Process  Control 

Reifer  [4] 

General  Strategy 

Capture  Artifacts  in  Rigorous,  Model-Based  Notation 

(Royce,  DSBTF)  [4,5] 

General  Strategy 

Strategic  Partnering 

Reifer  [4] 

Business  Strategy 

Relationship  Management 

Reifer  [4] 

Business  Strategy 

Market  Watch 

Reifer  [4] 

Business  Strategy 

Enterprise-Wide  Licensing 

Reifer  [4] 

Business  Strategy 

Independent  Expert  Reviews/SCEs 

(5000.2R,  DSBTF,  DSMC,  Jones) 
[6,5,10,4] 

Acquisition  Framework 

Performance-Based  Specifications 

(5000. 2R,  Anderson,  Reifer)  [6,  4] 

Acquisition  Framework 

Use  Past  Performance 

(5000. 2R,  DSBTF,  Anderson,  Reifer) 
[6,5,4] 

Acquisition  Framework 

Leverage  Commercial  Off-the-Shelf  (COTS  Items,  Non-Developmental  Items  (NDI) 

(Anderson,  Reifer)  [4] 

Acquisition  Framework 

Ensure  that  Subcontractors  Follow  Formal  Processes 

ESI  [8] 

Acquisition  Strategy 

Best  Value  Awards 

(5000. 2R,  DSBTF,  Anderson,  Reifer) 
[6,5,4] 

Acquisition  Strategy 

Adopt  Continuous  Risk  Management 

SPMN  16  Point  Plan  [7] 

General  Practice 

Estimate  Empirically  Cost  and  Schedule 

SPMN  16  Point  Plan  [7] 

General  Practice 

Use  Metrics  to  Manage 

SPMN  16  Point  Plan  [7] 

General  Practice 

Track  Earned  Value 

SPMN  16  Point  Plan  [7] 

General  Practice 

Track  Defects  Against  Quality  Targets 

SPMN  16  Point  Plan  [7] 

General  Practice 

Adopt  Life  Cycle  Configuration  Management 

SPMN  16  Point  Plan  [7] 

General  Practice 

Manage  and  Trace  Requirements 

SPMN  16  Point  Plan  [7] 

General  Practice 

Ensure  Data  and  Database  Operability 

SPMN  16  Point  Plan  [7] 

General  Practice 

Assess  Reuse  Risks  and  Costs 

SPMN  16  Point  Plan  [7] 

General  Practice 

Inspect  Requirements  and  Design 

SPMN  16  Point  Plan  [7] 

General  Practice 

Requirements  Trade-Off/Negotiation 

(DSBTF,  Royce)  [5,4] 

General  Practice 

Perform  Independent  Testing 

ESI  [8] 

General  Practice 

Have  Formal  Methods  of  Estimating  Software  Size 

ESI  [8] 

General  Practice 

Formally  Review  the  Functionality  of  the  System  the  Software  Replaces 

ESI  [8] 

General  Practice 

Use  Formal  Methods  to  Estimate  Schedule  and  Cost 

ESI  [8] 

General  Practice 

Use  System-Based  Software  Design 

SPMN  16  Point  Plan  [7] 

Development  Practice 

Define  and  Control  Interfaces 

SPMN  16  Point  Plan  [7] 

Development  Practice 

Design  Twice,  Code  Once 

SPMN  16  Point  Plan  [7] 

Development  Practice 

Manage  Testing  as  a  Continuous  Process 

SPMN  16  Point  Plan  [7] 

Development  Practice 

Compile  and  Smoke  Test  Frequently 

SPMN  16  Point  Plan  [7] 

Development  Practice 

Architecture-First  Approach 

(Royce,  DSMC,  DSBF)  [4,10,  5] 

Development  Practice 

Have  Common  Coding  Standards  for  Projects 

ESI  [8] 

Development  Practice 

Plan  Testing  Before  Coding 

ESI  [8] 

Development  Practice 

Establish  Reliability  and  Stress  Margins 

Doherty  SEI  [11] 

Acquisition  Practice 

Personal  Software  ProcessSM/Team  Software  ProcessSM  Practices 

Humphrey  [12,13] 

Maturity  Model 

Acquisition  Process  Improvement 

SEI  [14] 

Maturity  Model 

Contractor  Capability  Evaluation 

SEI  [15] 

Maturity  Model 

DSBTF:  Defense  Science  Board  Task  Force 
ESI:  Enterprise  Software  Initiative 
SCE:  Software  Capability  Evaluation 
DSMC:  Defense  Systems  Management  College 


SM  Team  Software  Process  and  Personal  Software  Process  are  service  marks  of  Carnegie  Mellon  University. 
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considered  to  successfully  migrate  prac¬ 
tices  from  project  to  project.  Before  man¬ 
agement  selects  specific  practices  to 
accomplish  a  project,  it  must  address  the 
organization’s  culture,  attitude,  and  experi¬ 
ence,  and  most  certainly  these  factors 
must  be  considered  when  management 
devises  its  strategy  to  introduce  the  prac¬ 
tices  selected  [16]. 

For  example,  early  identification  and 
removal  of  defects  through  consistent 
application  of  structured  inspections  is  a 
valuable  goal.  However,  if  the  organiza¬ 
tion’s  management  presumes  that  its  engi¬ 
neers  will  not  make  mistakes,  and  if  it  will 
not  adequately  fund  this  practice  consis¬ 
tently  from  concept  through  delivery,  the 
practice  is  not  realistic  given  the  organiza¬ 
tion’s  culture. 

Not  only  must  management  under¬ 
stand  its  organization’s  culture,  it  must 
also  understand  the  true  costs  and  risks 
associated  with  implementing  a  practice 
before  it  commits  to  using  the  practice. 
That  is,  management  must  honestly  assess 
and  understand  the  following: 

•  The  effect  of  the  practice  on  project 
teams  regarding  their  possible  resist¬ 
ance  and  the  potential  for  increased 
productivity. 

•  The  costs  associated  with  the  practice 
and  the  potential  return  on  invest¬ 
ment. 

•  The  cost  required  to  train  those  who 
will  apply  die  practice. 

•  The  availability  and  cost  of  associated 
tools. 

•  Potential  barriers  to  implement  the 
practice  and  its  application. 

•  The  validity  and  general  acceptance  of 
tire  practice  within  the  industry. 

•  The  effect  of  the  practice  on  related 
and  interfacing  practices,  processes, 
and  tools. 

•  The  degree  of  management  and  staff 
commitment  to  die  practice,  and  what 
factors  led  them  to  commit  to  the 
practice. 

It  is  critical  that  management  under¬ 
stand  tire  true  costs  and  impacts  of  the 
practices  it  implements,  whether  they  have 
been  proven  in  other  environments  or 
not.  If  management  implements  a  practice 
without  understanding  its  costs  and 
effects,  it  could  well  be  incompletely  or 
haphazardly  implemented,  and  the  project 
will  suffer  as  a  result.  Indeed,  if  the  imple¬ 
mentation  is  incomplete,  poorly  planned, 
or  otherwise  improper,  or,  worse,  if  the 
practice  must  be  replaced  mid-project,  the 
effects  -  such  as  poor  staff  morale  and 
productivity,  tool  replacement,  retraining, 
and  file  or  artifact  conversion  -  can  be 
devastating. 


In  addition  to  these  considerations,  proj¬ 
ects  with  substantial  software  content  that 
show  evidence  of  certain  characteristics  are 
poor  candidates  for  the  reasoned  applica¬ 
tion  of  best  practices.  These  characteristics, 
which  were  documented  in  the  April  2002 
CrossTalk  [17],  are  the  following: 

•  Unwarranted  optimism  and  unrealistic 
executive  management  expectations. 

•  Late  decision-making. 

•  Inappropriate  use  of  the  standard 
software  process. 

•  Missing  or  inadequately  implemented 
program  activities. 

•  Lack  of  leadership. 

•  Early  declarations  of  victory. 

•  An  absence  of  risk  management, 
which  could  convince  managers  and 
staff  they  can  accomplish  unrealistic 
objectives  given  the  actual  project  cir¬ 
cumstances. 

These  underlying  attitudes,  which  can 
be  understood  to  presume  project  success 
and  minimal  risk,  often  convince  project 
management  and  staff  that  they  need  not 
adequately  plan  to  implement  a  practice 
and  develop  process  standards.  Such  com¬ 
placency  can  be  costly. 

Given  the  fact  that  a  best  practices  sil¬ 
ver  bullet  does  not  exist,  organizations 
cannot  unthinkingly  adopt  a  pro  forma 
approach  to  project  completion  and 
assume  the  practices  drey  implement  will 
automatically  succeed.  To  truly  succeed, 
management  must  understand  how  the 
practices  they  use  will  work  within  their 
unique  organization,  which  will  lead  to  a 
solid  project  management  foundation  and 
will  in  turn  positively  affect  tire  bottom 
line  regarding  productivity,  quality,  timeli¬ 
ness,  and  user  satisfaction.^ 
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